The invention relates to a method for activating an operating system in a security module, to a security module as well as to the employment of a security module in an end device.
Security modules have system resources, in particular data interfaces for data input and/or data output, one or several central processing units CPU, coprocessors, volatile memory areas as working memory and non-volatile memory areas in particular EEPROM, ROM and/or FLASH. On the security module there are executed applications which while executed access the system resources of the security module. This access of the applications to the system resources is managed by an operating system of the security module. The operating system of the security module thus forms an interface between the system resources and the applications on the security module which are to be respectively executed.
If errors in the operating system are discovered or if it is established that a certain functionality is not contained in the operating system, for example a function, a method or a program code library, then missing or corrected operating system code parts, so-called patches, can be reloaded. For this purpose, jump-in addresses are defined, at which—instead of the erroneous/missing operating system code—the patch is executed. A return to the starting point of an application is then possible by means of defined return addresses in the patch.
In the DE 10 2007 003 580 A1 there is described the patching of a portable data carrier, wherein the patch is reloaded in the form of an executable application code into the data carrier and executed, which makes possible an installation of operating system parts during the operation of the portable data carrier.
This patching is elaborate and only leads to the correction or extension of small parts of the operating system. Therefore, from time to time a new version of the operating system is created. Security modules that are already in operation are then either exchanged or the update of the operating system is dispensed with.
It is desirable that the operating system in a security module is always kept updated to the latest development state. In this way, additional functions, restructurings in the operating system code, and improved performance of the security module can be achieved. In particular the errors discovered in the older version of the operating system in the past are corrected. As such an operating system update is extensive, this is not possible with the mentioned patching without considerable processing power losses of the security module.
From the DE 10 336 568 A1 it is known to implement an emergency operating system in a chip card, so that upon the occurrence of a major error during the operation of the chip card with the normal operating system there is ensured at least a minimum functionality of the chip card. But here many functions are not offered in the emergency operating system, so that the user of the chip card is severely restricted and endeavours to exchange the chip card as fast as possible.
From the U.S. Pat. No. 7,011,252 B1 it is known to incorporate two operating systems in the permanent non-volatile memory area (ROM) of a chip card. With the aid of the employed data interface there is employed either the one or the other operating system for executing an application. The operating systems here, likewise, are not updatable, i.e. errors in one of the operating systems also have to be corrected by means of patches.